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AUTOMATIC MOBILE CREW TRACKING SYSTEM WITH 



REMOTE ACCESS 



FIELD OF THE INVENTION 

This invention relates generally to management 
5 information systems and more particularly to automated 
systems and methods for field crew location and route 
planning. 

BACKGROUND OF THE INVENTION 

10 Businesses such as utility companies which deploy 

numerous employees over a wide geographic area to service a 
dispersed infrastructure or client base are faced with the 
particularly cumbersome task of communicating work 
assignments and related data to personnel that are dispersed 

15 in the field. For example, a utility company is faced with 
the daunting task of maintaining an infrastructure that spans 
a potentially very large geographic area. When outages occur 
in a utility grid, field personnel must be dispatched to 
address the problem. Typically, field personnel are already 

20 in the field when new service tasks or work orders are 

generated. Thus, utility companies are faced with the very 
complex task of receiving work orders, identifying field 
personnel that are best suited for the job, and communicating 
to field personnel that a particular work order has been 

25 assigned to them. 
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Typically, work orders are assigned to field crews on 
the basis of training and experience. However, another 
important consideration when assigning work orders is a field 
crew's proximity to the work area. Generally, a central 
5 dispatcher or operations manager has no automated means to 
locate field crews. Rather, an operations manager must rely 
on voice communications from field crews as to their 
location. Location data gathered from field crews may not 
always be accurate or even a useful description of the field 

10 crew's position. Further, manually maintaining field 

location data for multiple field crews can be an unwieldy 
task; doing so for a large number of field crews can be 
overly burdensome, if not impossible. Additionally, even if 
field location data is made available it must be applied to a 

15 map in order for it to be useful in calculating proximity to 
work sites and thereby making decisions as to work order 
assignments. Presently, this task also is completed 
manually. 

Thus, there is a need for an automated system and 
20 method for more advanced two way data communication between 
field personnel and a central office. In particular, there 
is a need for a system whereby accurate field location and 
position data is gathered for a field crew and automatically 
communicated to a central location or directly to other field 
25 crews deployed in the field. 

SUMMARY OF THE INVENTION 

Briefly, the present invention provides an automated 
system for gathering data related to the position of a field 
crew, communicating requests for the position data, and 
30 communicating the desired position in response to the 
request. The system comprises an enterprise computing 
system, at least one mobile field unit, and wireless 
communication network which supports transmission control 
protocol/internet protocol (TCP/IP) . A mobile field unit 
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comprises a receiver for receiving position data from a 
positioning service, a processor having instructions thereon 
for processing the position data, and a radio modem for 
communicating the position data over the wireless network to 
5 the enterprise computing system or other mobile field units. 
The enterprise computing network comprises application 
programs through position data may be requested and viewed, 
various server machines for storing and receiving position 
data, a local area network (LAN) connecting the server 
10 machines, and a gateway to the TCP/IP wireless network. Each 
mobile field unit and machine in the enterprise computing 
system has a unique IP address assigned to it. Accordingly, 
commands and position data can be communicated freely between 
all machines. 

15 According to another aspect of the invention there is 

provided a method for distributing position data. There is 
also disclosed a method for processing position data. 
According to still another aspect of the invention there is 
provided a method for formatting position data. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other features of the invention are further apparent 
from the following detailed description of presently 
preferred exemplary embodiments of the invention taken in 
25 conjunction with the accompanying drawings, of which: 
Figure 1 is a schematic diagram of a system in 
accordance with the present invention; 

Figure 2 is a diagram of software components of a 
system in accordance with the present invention; 
30 Figure 3 is a diagram of software components of a 

system in accordance with the present invention; 

Figure 4 is a diagram of a system in accordance with 
the present invention wherein data flow is shown directly 
between two mobile field units as well as between the mobile 
35 field units and the enterprise computing system; 
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Figure 5 is a flow diagram of process in accordance 
with the present invention for distributing mobile field unit 
position data; 

Figure 6 is an illustration of an exemplary screen for 
5 selecting a mobile field unit for which position data is 
desired; 

Figure 7 is an illustration of an exemplary screen for 
viewing mobile field unit position data; 

Figure 8 is a flow diagram of a process in accordance 
10 with the present invention for processing requests for 
position data; 

Figure 9 is a flow diagram of a process in accordance 
with the present invention for processing position data; 

Figure 10 is a flow diagram of a process in accordance 
15 with the present invention for formatting position data; 

Figure 11 is a diagram of software components and data 
flows in a system in accordance with the present invention; 
and 

Figure 12 is a diagram of software components and data 
20 flows in a system in accordance with a second embodiment of 
the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 

The present invention provides systems and methods for 
field crew location and task assignment. More particularly, 

25 the invention comprises an automated system for the 
distribution of field crew position data to a central 
location as well as to field personnel dispersed over a wide 
geographic area. In a system in accordance with the present 
invention, position data which may be any type of data 

30 related to the position of the mobile field unit is gathered 
at the mobile field unit. In one embodiment of the invention 
the data is received from a global positioning system (GPS) . 
For example, a system from Trimble Inc. may be used to 
deliver data in both standard and proprietary format. The 
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mobile field unit receives requests from other mobile field 
units and the enterprise computing system to transmit its 
position data. In response, the mobile field unit transmits 
the requested position data. The mobile field unit may also 
5 send position data on an interval basis in response to a 

request. In this case, a single request results in multiple 
instances of position data being transmitted. In the case 
that position data has been transmitted to the enterprise 
computing system, mobile field units may request the position 

10 data from the enterprise computing system. 

It should be noted that the present invention may be 
incorporated in a system that is employed to distribute work 
orders and related data in addition to field crew position 
data. Such a system is described in co-pending PCT Patent 

15 Application serial no. (not yet assigned) (attorney docket 

no. ABME-0538), filed on even date herewith, entitled "Mobile 
Crew Management System, " the contents of which are hereby 
incorporated by reference in their entirety. 

Figure 1 graphically depicts a system in accordance 

20 with the invention. As shown, the inventive system comprises 
enterprise computing system 50, mobile field units 52 and 53, 
and wireless communication network 54 . 

Enterprise computing system 50 may comprise database 
servers 56 for fielding requests to data stored in database 

25 58, hypertext transfer protocol (HTTP) servers 60 for 

fielding requests for web page data, monitoring server 62 for 
accepting and providing data regarding the status of work 
orders, file se rvers 64 , and UDP servers 65 for receiving 
mobile field unit position data and fielding requests for 

30 field position data. While each of servers 56, 60, 62, 64, 
and 65 is represented by a separate machine in Figure 1, in 
some embodiments of the enterprise system a single machine 
may be configured to perform all of these operations. An 
enterprise computing system may also comprise workstations 66 

35 from which various application programs may be accessed. 
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Servers 56, 60, 62, 64, and 65 and workstations 66 are 
interconnected through an Ethernet local area network (LAN) 
68. LAN 68 supports TCP/IP and each of machines 56, 60, 62, 
64, 65, and 66 is uniquely identified with an IP address. 
5 Gateway 70 provides a communication connection between LAN 68 
and wireless TCP/IP network 54. 

In a typical application of the inventive system, 
enterprise computing system 50 is located at a central 
office, operations center, or dispatching center. As is 
10 explained in greater detail below with reference to Figures 2 
and 3, position data for mobile field units 52 may be 
requested using an application program at enterprise system 
50. Upon receipt from the mobile field unit, the position 
data is stored on enterprise system 50. The position data 
15 may be displayed at enterprise computing system 50 and also 
may be transmitted upon request to mobile field units 52. 

Mobile field units 52 and 53 comprise position data 
unit 73. Position data unit 73 comprises position data 
receiver 75 having receiving antenna 77 operably connected 
20 thereto. Position data receiver 75 operates to receive 

positioning data from a global positioning system. Typically 
position data receiver 75 compiles latitude, longitude, 
velocity and direction data from the GPS system. Receiving 
antenna 77 typically operates by receiving signals from 
25 satellites and therefore may require line of site access to 
the satellites. Thus, when mobile field unit 52 is located 
within a vehicle, antenna 77 may be mounted on the exterior 
of the vehicle. 

Position data unit 73 also comprises wireless radio 
30 modem 74. Wireless radio modem 74 provides a means for 
communicating over wireless network 54 with enterprise 
computing system 50 and other field units. Wireless radio 
modem 74 supports point-to-point (PPP) protocol and TCP/IP 
protocol over wireless radio network 54. 
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Position data unit 73 further comprises processor 78 
which has stored thereon computer readable instructions for 
processing position data received at receiver 75. Processor 
7 8 is operable to communicate with radio modem 74 and is 
5 therefore able to communicate the processed position data to 
enterprise computing system 50 or other mobile field units 
via wireless network 54 . 

It should be noted that while the components of 
position data unit 73, i.e. receiver 75, radio modem 74, and 

10 processor 78, are shown separately in Figure 1, these 

components might be embodied in a single physical device. 

Mobile field units 52 and 53 optionally may comprise 
computing device 72 which may be a portable computer, a 
personal digital assistant (PDA), or similar device. 

15 Typically computing device 72 comprises a processor, random 
access memory (RAM) , web browser software for internet and 
intranet communications, and an interactive display 
mechanism. Computing device 72 may also include: storage 
capability (flash or electro-mechanical) , a serial interface, 

20 an audio playback device, and software to support a TCP/IP 

protocol stack and PPP protocol. It should be noted that any 
or all of the components of position data unit 73, i.e. 
processor 78, radio modem 74, and receiver 75, may be 
embodied in computing device 72. 

25 Mobile field units 52 and 53 optionally may also 

comprise a wireless two-way voice communication device 76. 
Device 7 6 may be integrated with computing device 72 or may 
be a separate radio device, cellular phone, or digital 
cellular phone. 

30 Each field crew is assigned a mobile field unit. Thus, 

although only two are shown in Figure 1, numerous mobile 
field units may be deployed and operating at once. Each 
mobile field unit 52 has an IP address assigned to it. 
Further, enterprise computing system 50 comprises a database 

35 of entries indicating for each field unit, the field crew 
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which has the unit. Thus, when field unit position data is 
needed or a work order is assigned to a particular field 
crew, the inventive system automatically routes the 
appropriate commands and data as described below and in co- 
5 pending PCT Patent Application serial no. (not yet assigned) 
(attorney docket no. ABME-538) entitled "Mobile Crew 
Management System, " to the appropriate mobile field unit. 
Field crews are free to access enterprise computing system 50 
to gather position data for other field crews or to gather 
10 data that may be helpful in completing an assigned work 

order. Furthermore, field unit position data may be accessed 
at a first mobile field unit 53 directly from another mobile 
field unit 52 without accessing enterprise computing system 
50. 

15 Wireless radio network 54 provides TCP/IP communication 

between enterprise computing system 50 and mobile computing 
devices 52 and 53. As previously noted, each mobile field 
unit 52 is given a unique IP address. Similarly, machines on 
enterprise computing network 50 are given a unique IP. 

20 Because wireless radio network 54 supports TCP/IP, routing of 
data and commands between mobile field units 52 and 53 and 
enterprise computing system 50 can be accomplished by 
existing network techniques. Further, mobile field units 52 
and 53 can be arranged into various network configurations 

25 such as subnets and intranets and in theory, if the 

appropriate gateways are arranged, can be accessed via the 
Internet . 

IP addressing allows for commands to be routed to, and 
data accessed from any machine in the network. Thus, data 
30 and/or a command may be transmitted via gateway 70 to 

wireless radio network 54 and delivered at any particular 
mobile field unit 52. Similarly, data and/or a command may 
be transmitted from mobile computing device 52 via modem 74 
to wireless network 54 which delivers the data and/or command 
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to a particular machine designated by a unique IP address on 
enterprise computing system 50. 

Preferably, wireless network 50 employs native TCP/IP. 
However, any network type may be employed provided it can be 
5 adapted to support TCP/IP. Thus, wireless network 54 may be 
any of the following network types: a CDPD public network 
(packet-switched) ; a radio packet-switched network (adapted 
for TCP/IP) ; a tariff /non-tariff -based network; or a Personal 
Communication Systems network (circuit-switched) . A system in 

10 accordance with the invention can be implemented at any 
location that one of these network types exists. These 
alternative communication networks are discussed in greater 
detail in co-pending patent application entitled "Mobile Crew 
Management System. " 

15 Two alternative embodiments of the software components 

of the present invention are described below. A first 
embodiment employs UDP client and servers on enterprise 
computing system 50 and mobile field unit 52 to communicate 
field crew position data. A second embodiment employs an 

20 HTTP server on mobile field unit 52 and an HTTP client on 
enterprise computing system 50. Both embodiments are 
operable to pass field unit position data to enterprise 
computing system 50 or other field units 53. 

Figure 2 is a diagram of software components comprised 

25 in a first embodiment of a system in accordance with the 
present invention wherein UDP technology is employed to 
communicate field unit position data. As shown, in 
enterprise computing system 50, numerous application program 
components or clients 80 may exist. Preferably these are 

30 written using the JAVA programming language so as to be 
operable on platforms running various operating systems. 
Each application 80 may serve a particular purpose with 
respect to managing work orders and monitoring the progress 
of those work orders. UDP position tracking application 83 

35 is employed by operators of the system to manage position 
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data for various mobile field units. In particular, UDP 
tracking application 83 may be employed to request position 
data for a particular mobile field unit 52. It should be 
noted that there may be multiple instances of the same 
5 application 80, 83 running at any one time. Additionally, 
remote applications 81 from outside system 50 may also 
occasionally access system resources. 

Enterprise computing system 50 also comprises a UDP 
server 87. UDP server 87 operates to receive and store 

10 position data received from mobile field unit 52 and 53. 
Common gateway interface (CGI) 8 9 is employed to retrieve 
position data and format the position data in response to 
requests for such data. According to one embodiment of the 
invention CGI 89 is written in the PERL scripting language. 

15 Enterprise computing system 50 also comprises database 

server software 82 which may be, for example, an Oracle 
database server. Indeed, there may be multiple databases 82 
in one system 50. Database server software 82 manages field 
unit position data, work order data as well as other business 

20 related data. For example, in the case of a utility, 

databases 82 might comprise detailed equipment data and map 
data . 

Enterprise computing system further comprises HTTP 
servers 84 which may be, for example, a Netscape or Apache 

25 HTTP server. HTTP servers 84 are operable to field requests 
from all machines but particularly from web browsers located 
in mobile field unit 52. 

Monitor server software 85 accepts updates from 
applications 80 indicating that a work order has been 

30 assigned. Monitor server software 85 also accepts updates as 
to whether the work order has been successfully transmitted 
to field unit 52 and whether it was accepted by the field 
crew. Monitor server 85 also provides a report generation 
feature. 
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Mobile field units 52 and 53 comprise various software 
components associated with position data unit 73. It should 
be noted that while mobile field unit 53 comprises position 
data unit 73, the specific software components of data unit 
5 73 are shown only in field unit 52 for purposes of brevity. 
Position data unit 73 comprises UDP server 95 for receiving 
requests for position data. Preferably, UDP server 95 is 
multi-threaded meaning that it listens for requests and upon 
receipt of requests, spawns UDP client 96 to gather the 
10 requested position data and transmit it back to UDP server 87 
on enterprise computing system 50. In this way, UDP server 
96 can continue to listen for additional requests. 



for interfacing with receiver 75. GPS processing software 98 

15 processes data received from receiver 75 into an internally 
recognizable format. TCP/IP stack 99 is employed to 
communicate with radio modem 74. PPP server 100 may be 
employed to interface with other devices in mobile field unit 
52 such as mobile computing device 72. 

20 Mobile field .unit 52 may also comprise mobile server 

application 86. Mobil server application 86 services 
requests from enterprise computing system 50 to mobile field 
unit 52. In a preferred embodiment, mobile server 86 is 
written in the JAVA programming language which allows for 

25 mobile server 8 6 to run on numerous hardware platforms 

running various operating systems such as Windows, Mac OS, or 
Unix. Mobile server 86 is multi-threaded meaning it listens 
for requests and upon receipt of an input, spawns process 88 
to react to the input. In this way, mobile server 8 6 can 

30 continue to listen for additional requests. 



which may be loaded with files 92 that are downloaded from 
enterprise computing system 50. Web browser enhancer 94 is 
loaded by web browser 90 to display maps and related data. 
35 Web browser enhancer 94 may be a plug-in that is initially 



Position data unit 73 also comprises GPS interface 97 



Mobile field unit 52 also comprises web browser 90 
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stored on mobile field unit 52. Alternatively, web browser 
enhancer 94 may be an Applet that is downloaded from 
enterprise computing system 50. 

Figure 3 provides a view of the software components of 
5 an alternative software embodiment in accordance with the 
present invention that employs HTTP communications for 
distribution of field unit position data. As shown, the 
majority of software components are identical to those from 
the UDP embodiment described above with reference to Figure 

10 2. However, with regard to enterprise computing system 50, 
where in the previous embodiment UDP server 87 and UDP 
position tracking application 83 were employed to retrieve 
field unit position data, in the embodiment of Figure 3, HTTP 
client application 110 both requests and receives field 

15 position data from mobile field unit 52. 

With regard to mobile field units 52 and 53, position 
data unit 73 comprises HTTP server 112 for receiving and 
responding to requests for field unit position data. HTTP 
server 112 interacts with common gateway interface (CGI) 

20 program 114 to retrieve position data. Other components of 
position data unit 73 include receiver interface software 97, 
position processing software 98, and TCP/IP interface 
software 99 all of which operate identically to those shown 
in Figure 2 above. 

25 Mobile field units 52 and 53 might also comprise 

various other components including mobile server 8 6, process 
88, web browser 90 and web browser enhancer 94. These too 
operate as described above with reference to Figure 2. 

Generally, mobile field unit 52 gathers position data 

30 from a positioning system and transmits position data to 

machines upon request. The requesting machine may be another 
mobile field unit 53 or a machine on enterprise computing 
system 50. Where the data is transmitted to enterprise 
computing system 50, the position data is stored and 
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distributed upon request to other mobile field units 53 or 
client applications 80 and 83. 

Where position data is delivered directly from one 
mobile field unit to another, i.e. peer-to-peer, a mobile 
5 field unit 53 may operate as a mobile command center. As 
such, movement of mobile file units can be tracked on a 
mobile field unit. Furthermore, by delivering position data 
to both the computing system 50 and mobile field unit 53, the 
location of a mobile field unit 52 can be simultaneously 

10 tracked in both locations. In theory, numerous mobile field 
units may track the position data for one or more mobile 
field units. With the advent of unlimited usage CDPD, 
offerings the above scenarios become very attractive. This 
is due in particular to the relatively low overhead 

15 associated with UDP packets. Figure 4 illustrates 

connections being made directly between mobile field units 52 
as well as between mobile field units 52 and enterprise 
computing system 50. One mobile field unit may be configured 
as a mobile control center and receive position data that is 

20 simultaneously transmitted to enterprise computing system 50. 
Figure 5 provides a flow chart for the process of 
distributing position data from a mobile field unit 52 or 53. 
As shown, at step 120 position data for field unit 52 is 
gathered. At step 122 a request to transmit the position 

25 data to a particular machine, preferably identified by an IP 
address is received at mobile field unit 52. As explained in 
detail with reference to Figure 8 below, the request may be 
for either immediate transmittal of position data or for 
transmittal of position data at specific intervals. An 

30 exemplary screen for specifying a particular machine for 
which position data is desired is shown in Figure 6. 
Referring back to Figure 5, at step 124, depending upon the 
IP address specified in the request, the position data is 
routed over wireless network 54 to either another mobile 

35 field unit 53 or to enterprise computing system 50. If the 
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data is routed to enterprise computing system 50, at step 126 
the position data is processed and stored in enterprise 
system 50. Thereafter, at step 128 enterprise computing 
system 50 in response to a request for position data from a 
5 mobile field unit 52 retrieves the stored position data. At 
step 130, the position data is formatted into a format which 
can be easily processed by a requesting mobile field unit. 
As will described below, typically this formatting step 
entails generating a file with a MIME type with the position 

10 data located therein as well as an HTML file with an embedded 
reference to the MIME file. At step 132, the formatted 
position data is transmitted to the mobile field unit. At 
step 134, requesting mobile field unit 53 loads the position 
data into web browser 90. Figure 7 is an exemplary screen 

15 showing plotted position data. 

If at step 124, the position data was routed directly 
to a mobile field unit 53, at step 136 field unit 53 formats 
the position data. In this, the peer to peer scenario of 
transmitting position data, the position, velocity, and 

20 direction data is extracted from the received packets or data 
link. Typically, in the peer-to-peer scenario, history 
records are not maintained of position data, i.e. the 
previous position data is deleted. Thus, formatting of 
position data upon receipt at a mobile field unit directly 

25 from another mobile field unit may entail replacing the 

previous position data with the new position data. At step 
138 the refreshed position data is loaded and displayed in 
web browser 90 with the aid of web browser enhancer 94. 
It should be noted that because history records are typically 

30 not maintained in the peer-to-peer scenario, if a crew wishes 
to display more than the current position for mobile field 
unit 52, i.e. the route, it is necessary to obtain this 
information from enterprise computing system 50. 

At step 122 in Figure 5 a request for position data is 

35 processed at mobile field unit 52. Figure 8 provides a 
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detailed flow diagram of a process for processing a data 
request. As shown in Figure 8, at step 142 a request for 
position data is received at mobile field unit 52. The 
request may vary in terms of what exactly is requested. The 
5 request may be for position data to be sent immediately. 

Alternatively, the request may indicate that position data is 
to be transmitted periodically over specific intervals. The 
interval may be defined in terms of time or distance traveled 
by the mobile field unit 52. Furthermore, the request may 

10 define a primary and secondary device to which the position 
data should be transmitted. Communication of position data 
to a primary and secondary machine allows for the enterprise 
computing system 50 as well as another mobile field unit 53 
to simultaneously monitor field locations for field unit 52. 

15 If at step 144 the request is for immediate 

transmittal, at step 146 position data is immediately 
transmitted to the requesting machine. In an embodiment of 
the present invention such as is shown in Figure 2 wherein a 
UDP server 95 is employed in position data unit 73, the IP 

20 address and port number of the requesting machine may be 

extracted from the UDP packet of the request and the position 
data immediately transmitted to the address and port number. 

If at step 144 the request is for position data to be 
sent at specified intervals, at step 148 position data is 

25 transmitted to the primary machine and possibly secondary 

machine as specified in the request. Thereafter, at step 150 
it is determined if the specified interval, for example time 
or distance traveled, has been reached. If so, at step 148 
updated position data is transmitted. If at step 150 the 

30 interval has not been reached, the process continues to wait 
at step 152. 

In Figure 5, at step 126 enterprise computing system 50 
processes the position data received from mobile field unit 
52. The process steps that may be employed in the format 
35 operation are depicted in Figure 9. At step 160 the position 
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data received from mobile computing unit 52 is parsed. At 
step 162 latitude and longitude coordinates are calculated 
from the parsed position data. These latitude and longitude 
coordinates were taken relative to the earth' s curved surface 
5 by the GPS system. A two-dimensional map such as exists in 
mobile field unit 53 does not account for the curvature of 
the earth. Thus, when mapping the GPS coordinates to two 
dimensional planar coordinates, it is necessary to adjust the 
coordinates. This occurs at step 164 where the latitude and 

10 longitude coordinates are converted to two-dimensional planar 
coordinates, usually for the state or region where field unit 
52 is located. At step 166 velocity and direction statistics 
are extracted from the parsed position data. At step 168 the 
formatted position data is stored for later retrieval. As is 

15 explained in greater detail below, the position data may be 
stored in either a file or system database. 

In Figure 5, at step 130 upon request of a mobile field 
unit, enterprise computing system 50 formats the position 
data in preparation for transmittal to a field unit. Figure 

20 10 provides a detailed flow chart of the formatting process. 
At step 180 the formatted position data is stored in a first 
file. This first file is preferably a MIME file type and has 
a file name that ends with a ".mpx" extension. The 
formatting of the .mpx file is analogous to that described in 

25 co-pending PCT Patent Application serial no. (not yet 

assigned) (attorney docket no. ABME-0538) , filed on even date 
herewith, and titled "Mobile Crew Management System." 
However, where in that application the data in the .mpx file 
represents map objects, in this case the data represents a 

30 series of position data points for a mobile field unit at 

various points in time. The series of position data points t 
can be connected and displayed as markers on a map to 
represent the route that a mobile field unit 52 has taken. 
Each marker represents an actual measurement. Different 

35 markers may be used to represent different mobile field 
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units. At step 182 a second file is generated. This second 
file is preferably an HTML file which can be loaded by web 
browser 90. The HTML file comprises an embedded reference to 
the .mpx file. Upon loading of the HTML file, web browser 90 
5 detects the reference to the first file, i.e. the ".mpx" file 
and loads web browser enhancer 94 which is specially 
developed to display the contents of the .mpx file. In 
addition to performing other functions, web enhancer 94 
overlays the route with land-based and network maps. The 
10 field location data can thereby displayed be in the web 
browser . 

As noted previously, the present invention may be 
implemented using UDP technology or HTTP technology to 
transmit position data. Figure 11 depicts various command 

15 and data flows associated with transfer of position data that 
may be implemented in an embodiment of the invention 
employing UDP technology. The distribution of position data 
may begin with UDP position tracking application 83 at 
enterprise computing system 50 requesting, as shown by arrow 

20 200, that, position data for mobile field unit 52 be 

transmitted back to the enterprise computing system 50. At 
mobile field unit 52, the request is received at UDP server 
95 (arrow 200) . UDP server 95 spawns UDP client 96 to service 
the request (arrow 202) . After retrieving the position data, 

25 UDP client 96 transmits the requested position data to UDP 

Server 95 on enterprise computing system 50 (arrow 204) . UDP 
server 95 parses the position data, retrieves the latitude 
and longitude coordinates as well as the velocity and 
direction statistics, and converts the latitude and longitude 

30 coordinates to state plane coordinates. UDP Server 87 stores 
the processed position data with an indication of the IP 
address of mobile field unit 52. Generally, the processed 
position data is stored (arrow 206) in a system log file, 
referred to as gps . log 210. The position data is typically 

35 also saved in database 82 (arrow 208) . The position data can 
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thereafter be retrieved from either location. It should be 
noted that flows 204 through 208 may be repeated on an 
interval basis if it was initially requested that the 
position data be so delivered. Where updated position data 
5 is repeatedly delivered on intervals over a period of time, 
the gps.log file and database 82 are appended to with the 
updated position data. 

Generally, when a field crew or individuals at the 
enterprise computing system 50 desire to see position data 

10 for a particular field unit 52, they may do so by accessing 
the position data stored on enterprise computing system 50 
via a web interface. In Figure 11, this process of accessing* 
the stored position data is illustrated by means of an access 
from a mobile field unit 53. It should be noted, however, 

15 that this same process could be initiated from other 

locations including clients on enterprise computing system 
50. 

Typically, a user may specify the particular machine 
for which they wish to have position data using a web page 

20 such as that shown in Figure 6. As shown in Figure 6 a user 
may select a particular field unit 52 by selecting the IP 
address for the desired machine. Of course, other means of 
designating a particular mobile field unit 52 could 
alternatively be used, provided it uniquely identifies the 

25 unit. 

For purposes of this exemplary illustration, it can be 
assumed that a request is made at field unit 53 for position 
data for field unit 52. At field unit 53, the request for 
position data is transmitted, as represented by arrow 212, to 

30 HTTP Server 84 on enterprise computing system 50. The 

request identifies that position data for field unit 52 is 
desired by including the IP Address of field unit 52. In one 
embodiment of the invention, flow 212 corresponds to an HTTP 
CGI Post connection between web browser 90 and HTTP server 

35 84. 
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In response to the request, HTTP server 84 launches a 
CGI 89 which is preferably implemented as a PERL script 
(arrow 214) . Using the IP address that was transmitted with 
the request, PERL script 89 searches for the stored position 
5 data. The position data may be stored in both a log file, 
gps.log 210, and database 82. The position data may be 
retrieved from either location using the IP address. For 
example, PERL script 89 may search gps.log file 210 for all 
position data related to the designated IP address. 

10 Generally, the position data that is stored in 

enterprise computing system 50 has been gathered over 
intervals and may contain some inaccuracies in the position 
data. Thus, PERL script 89 may need to process the position 
data to account for these inaccuracies. Generally, PERL 

15 script 89 parses each line of gps.log file 210 or each record 
of database 82, extracting the state plane coordinates 
related to field unit 52. PERL script 89 stores the previous 
and current coordinates and checks for sudden changes in 
value. If the values are negative then they are ignored. 

20 Typically, negative values are an indication that the 

positioning system had not achieved a lock on the particular 
field unit when the position data was generated, 

PERL script 89 may also ignore values for position data 
if the value represents a sudden change in position of the 

25 field unit that cannot be accounted for. PERL script 89 can 
delineate between spurious sudden change values and valid 
position data by considering values in relation to those that 
come before and follow. According to this sliding window 
algorithm, if a value represents a sudden change in position, 

30 but subsequent values for the position are consistent with 
this value, i.e. within a reasonable proximity, the value is 
considered to be valid. Such a sudden change may be caused 
for example when the field unit was off and subsequently 
turned on when the field unit was in an entirely new 
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location. If the change cannot be accounted for, however, it 
is discarded. 

All position data values that are found to be valid are 
written to a first file 216 (arrow 218) . In one embodiment 
5 the first file 216 is a MIME type file and has a file name 
ending ".mpx." Thereafter, PERL script 89 generates a second 
file 220, preferably an HTML file (arrow 222) . HTML file 220 
comprises a reference or an embedded tag to ".mpx" file 216. 
HTML file 220 and ".mpx" file 216 are transmitted via HTTP 

10 server 84 to field unit 53 (arrow 224). Upon receipt, HTML 
file 220 is loaded into web browser 90. Web browser 90 
recognizes the reference to M .mpx" file 216 and in response 
loads web browser enhancer 94 which is operable to display 
the position data stored in ".mpx" file 216 (arrow 226). An 

15 exemplary screen that may be displayed upon loading of the 
position data in browser 90 is shown in Figure 7. 

It should be noted that the display preferably 
graphically displays the velocity and direction to a location 
for each mobile field unit. For example, attached to each 

20 icon or marker on the map display, a vector may be drawn. 
The vector indicates direction of travel and the length of 
the vector is an indication of the speed of the mobile field 
unit. Of course, the velocity may also be drawn as text on 
the display. 

25 It should also be noted that M .mpx" file 216 may 

encompass land-based data representing a sub-map which 
encompasses the coordinates of the mobile field unit route. 
Thus, browser enhancer 94 can overlay the mobile field unit 
route on a land-based map display. ".mpx" file 216 and html 

30 file 218 typically should have unique names. Otherwise, upon 
subsequent requests for position data for the same field 
unit, web browser 90 may display old map data instead of the 
newly downloaded data. Unique file naming mechanisms may 
include, for example assigning file names corresponding to 

35 the time and date a file was generated or by assigning unique 
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random numbers. A complete description of the contents and 
uses of ".mpx" file 216 and HTML file 218 is provided in co- 
pending PCT Patent Application serial no. (not yet 
assigned) (attorney docket no. ABME-0538), filed on even date 
5 herewith, and titled "Mobile Crew Management System," the 
contents of which are hereby incorporated by reference. 

As previously noted, position data may be transmitted 
directly from one mobile field unit to another mobile field 
unit without first being stored on enterprise computing 

10 system 52. Thus, for purposes of illustration, a user at 
field unit 53 may designate to retrieve position data 
directly from field unit 52. Accordingly, a request is 
forwarded from web browser 90 of field unit 53 to UDP server 
95 of field unit 52 (arrow 230) . UDP server 95 launches UDP 

15 client 96 to gather the requested position data (arrow 232) . 
UDP client 96 gathers the data and transmits it back to field 
unit 53 (arrow 234) . Web browser 90 of field unit 53 
receives the position data and loads web browser enhancer 94 
so as to display the new position data (arrow 236) . 

20 It should be noted that typically requests for position 

data might first designate a primary and secondary machine by 
IP address and the port location which are to receive 
position data. Thereafter, in response to these requests, 
UDP packets containing position data are transmitted to the 

25 primary and secondary machines. Position data may be 

transmitted at intervals if specified as such in the request. 
Of course if no primary or secondary addresses are specified, 
position data is not sent. Thus, the first embodiment of the 
invention allows for two or more machines to simultaneously 

30 receive position data for the same mobile field unit. As 
noted previously, this allows for a mobile field unit to 
receive position data and operate as a mobile control center 
while position data is simultaneously provided to enterprise 
computing system 50. 
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A second embodiment of the system for distributing 
position data employs HTTP communications to distribute 
position data from a mobile field unit. Figure 12 depicts 
the data and command flows for such an embodiment. Typically 
5 a request for position data is made via HTTP position 

tracking application 110 and involves making an HTTP client 
connection with the selected mobile field unit 52 (arrow 
300) . Upon receipt, HTTP server 112 requests CGI program 114 
handle gathering the requested position data (arrow 302). 

10 CGI program 114 requests position data from position 

processing application 98 (arrow 304). Position processing 
application 98 returns the requested position data to CGI 
program 114 (arrow 306) . CGI program 114 returns the 
position data to HTTP application 110 (arrow 308) . HTTP 

15 application 110 stores the position data in gps . log file 210 
and database 82 (arrow 310) . 

The process of retrieving position data from enterprise 
computing system 52 to mobile field unit 53 in the system of 
Figure 12 is generally identical to that described above with 

20 reference to Figure 11. As such, the numbering for the 
corresponding flows (arrows 212 through 226) have been 
numbered the same. 

In the case of retrieving position data from field unit 
52 directly to field unit 53, the process is only slightly 

25 different from that described above in connection with Figure 
10. Accordingly, a request is forwarded from web browser 90 
of field unit 53 to HTTP server 112 of field unit 52 (arrow 
330) . HTTP server 112 launches CGI program 114 to gather the 
requested position data (arrow 332) . CGI program 114 gathers 

30 the data and transmits it back to field unit 53 (arrow 334). 
Web browser 90 of field unit 53 receives the data and loads 
web browser enhancer 94 so as to display the new position 
data (arrow 336) . 

Although the flow is generally same for the UDP and 

35 HTTP implementations of the present invention. There are a 
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few slight differences in the capabilities of the systems. 
The present implementation does not provide for position data 
to be transmitted at intervals as a result of a single 
request. Rather, a request is typically sent each time 
5 position data is required, even for updates. Of course it is 
possible and certainly envisioned that an HTTP embodiment 
that allows for transmission of position data at intervals. 
Furthermore, the HTTP embodiment does not presently provide 
for a single request that results in a primary and secondary 

10 machine to be designated and simultaneously receive position 
data. However, this functionality can be duplicated in the 
HTTP embodiment by generating a list of machines to which 
position data should be transmitted, and each time position 
data is requested, a request is made for each machine in the 

15 list. 

Thus, as described above the present invention provides 
systems and methods for low-cost and timely communication of 
field unit position data between a field unit, a central 
enterprise system, and secondary field units. The system 

20 comprises an enterprise computing system, a wireless network, 
and multiple mobile field units. Communications are 
TCP/IP-based and can be carried over a public or private 
network using a variety of communications technologies. 

While the invention has been described and illustrated 

25 with reference to specific embodiments, those skilled in the 
art will recognize that modification and variations may be 
made without departing from the principles of the invention 
as described above and set forth in the following claims. In 
particular, the present invention has been explained with 

30 reference to an exemplary utility environment but may be 
employed in other environments such as maintenance service 
corporations, ambulance services, public safety systems or 
any other operation which communicates work orders to field 
personnel. Furthermore, it should be noted that position 

35 data may be displayed according to the methods and systems of 
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the present invention in an application other than a web 
browser. Accordingly, reference should be made to the 
appended claims as indicating the scope of the invention. 



